Welcome to Mercury/32 version 3.01!

Mercury/32 is a version of the Mercury Mail Transport System specially engineered for Windows 95/98/NT 4.0 and 2000 systems. The Mercury MTS is a proven, powerful Internet mail transport originally released as a set of NetWare(tm) NLMs, designed to run on Novell NetWare file servers. This version takes full advantage of the threading and pre-emptive multitasking of modern Windows systems to provide an extremely smooth, powerful mail transport with a host of features, yet one that has negligible impact on the system on which it runs.

What's new in this version?

Year 2000 Compliance

Overview of the system - what is Mercury?

License and terms of use

System requirements

The configuration file, MERCURY.INI

Mailing lists

The POP3 Server

The Mail Server

Manuals

The Mercury Mail Transport System, Copyright © 1993-99, David Harris, all rights reserved.


What's new in this version?
What's new in this version of Mercury/32?

Mercury v3.01 is a major upgrade of the system

New in v3.01

MercuryE, full SMTP delivery module  Mercury now includes two SMTP client modules - the original MercuryC relay module and a new MercuryE module which performs full end-to-end SMTP delivery. Using MercuryE obviates the need for a "smarthost", since Mercury can delivery directly to all addresses.

Mail filtering  Pegasus Mail was the first mail program in the industry to have comprehensive mail filtering, way back in 1991. Now Mercury/32 has it as well. You can use filters to do just about any kind of specialized processing on your incoming mail, including printing, audit trailing, forwarding and list management. Mercury's filtering will be very familiar to anyone used to using Pegasus Mail's filtering system, and it's just as fast and reliable.

MercuryW, Password change server  In response to requests from our users, we've provided a module that allows POP3 users to change their passwords. MercuryW uses the poppassd protocol, which makes it compatible with Eudora and with Pegasus Mail, by fitting the Pegasus Mail "poppass" extension, which is provided in the RESOURCE subdirectory of the directory where you have installed Mercury/32 v3.01 (please read POPPASS.TXT for information on installing and using this extension).

New statistics manager  Mercury now gathers comprehensive statistics as it runs and presents them in a continuously updated statistics manager window. Statistics can be periodically saved to files or e-mailed out, and can be very useful for tracking the performance and usage of your system.

Completely redesigned user interface  Mercury/32's user interface has been completely overhauled in this release. Users should now find it dramatically more intuitive and attractive than in previous versions.

NetWare support modules updated  Mercury's NetWare support modules have been heavily updated in v3.01, and are now much more reliable and robust than in previous versions. Full support is provided for NetWare 3.11 and later, including NetWare 4.x and 5.x. You can choose to run in either Bindery mode, or in NDS mode. A personality module for Windows NT Server systems is also in development at the time of writing.

Lots and lots of smaller goodies  Including a system messages window for monitoring the activity of the system, a MercuryS killfile option allowing you to suppress mail from users or entire domains, vastly improved Daemon interface, retry controls for the queue processor, support for Authenticated SMTP in MercuryS, and faster performance on almost all operations.

Other fixes  V3.01 fixes the MSTATUS and MSET commands, which were inoperative in v2.16; it also includes better postmaster notifications for delivery failures, and significantly improved handling of 400-series errors issued by the smart host during outwards mail delivery. Several significant bugs, including a problem with leaking file handles, have been addressed in v3.01, and problems have been corrected with both the ReMail and Notification features.

New in V2.15/V2.16

V2.16 contains very minor bug fixes over v2.15.

MercuryX Scheduler Module improved even further  Even more changes have been made to the MercuryX scheduler module. It now has an option that tells it to allow your client processes to complete their normal processing cycles even if doing so runs past the end of the connection slot. MercuryX now also has a Poll now button which you can use to force a connection cycle at any time.

Help files integrated and improved  All the Mercury help is now in the one file, making it much easier to navigate between topics. Indexing has also been improved in the new help file.

Multiple Interface Support  The Mercury server modules now allow you to specify which interface they should use on systems that have more than one IP address.

"Pause" and "Poll now" buttons added  All the Mercury protocol modules now have a Pause checkbox which will temporarily prevent them from processing jobs. Servers will politely refuse connections, and clients will simply not access the queue. The client modules, the core module and MercuryX also have new Poll now buttons which can be used to force a processing cycle at any time.

NetWare NDS Mode support  A Network Support module for Novell NetWare 4.x servers in NDS mode is now included with Mercury. The module is still essentially a "work in progress", but works well enough to be released. To run in NDS mode, you will need the Pegasus Mail NDS enabler set, available from ftp://risc.ua.edu/pegasus/winpmail/wpmnds20.zip.

Daemon Interface complete and documented  Probably the most powerful and least visible feature of Mercury/32 is its Daemon (or plugin) Interface. V2.15 is the first version to have a complete, working, documented version of the interface and we expect to begin seeing the release of Daemons for Mercury/32 in the very near future. For full documentation on the Daemon interface, along with some sample source code, see the files DAEMON.TXT, DAEMON.H and TEMPLATE.ZIP in the RESOURCE subdirectory of the directory where you installed Mercury/32.

Password options for moderated list commands  You can now set passwords on your moderated mailing lists in Mercury/32. Only people knowing a valid password will be able to issue the moderator commands MSET, ADD, REMOVE and MSTATUS for that list. Two different password strategies are provided - see the help on distribution lists in the program for more details.

New mail server commands for mailing lists  Users can now send the mail server a STATUS command for any given list to find out their subscription options. Moderators can send an MSTATUS command to find out the subscription status of any member in the list.

Session logging hot switchable  The Mercury protocol modules have for quite some time supported a feature called "session logging", in which complete transcripts of all the sessions they establish are kept in files on the local system. Originally intended as a debugging aid, this feature has proven itself so useful that we've now rolled it into the system as a standard option that can be turned on and off in each module's configuration dialog.

New in V2.14

MercuryX Scheduler Module improved   The MercuryX scheduling module has been heavily beefed up and now allows you to define commands that should be executed before and after each scheduling cycle - this could, for instance, be used to invoke dialers, or to run network connectivity programs prior to establishing mail connections. For more information on these options, please click the Help button in the MercuryX Task Scheduler configuration dialog. MercuryX also now has support for the dial and hangup commands that are a standard part of Windows 98 - if you are running Mercury on a Win98 system, use these commands to control your dial and hangup state. If your ISP's SMTP server supports the ETRN command as a means of "kickstarting" a remote queue, MercuryX can now issue that command for you. Finally, MercuryX now has an option where it will only start and stop client processes, leaving server processes running to allow local access.

PH Query Server  By installing the MercuryH PH Query server, you can offer comprehensive directory services for your system to anyone using a PH client (Pegasus Mail and Eudora both have built-in PH clients, and the protocol is commonly-used on unix systems). MercuryH answers queries using information from a Pegasus Mail addressbook you supply.

Finger server   Mercury/32 now includes a Finger Server protocol module; the primary use for this module is expected to be the provision of information like public keys and phone numbers. To enable the finger server in an existing Mercury/32 setup, copy MERCURYF.DLL to the directory where Mercury/32 is installed and add "mercuryf.dll" to the [Protocols] section of your MERCURY.INI. The Finger Server will return the contents of a file called PROFILE from the user's new mail directory if it can find one there.

Relay suppression options   Mercury/32 now allows you to control relaying of mail. Relaying is  the standard SMTP process of mail delivery, under which any SMTP host will accept a message from any user to any other user, even if neither of those users is local on the SMTP system itself. Relaying is the principal reason that Internet e-mail works at all, but recently it has been heavily abused by sociopaths who distribute bulk unsolicited e-mail ("spam"). Mercury/32 now allows you to specify that mail can only be delivered if either the sender or the recipient is local, and has a strict mode where mail will only be accepted from a local sender address if the incoming connection is from an approved machine. For more information on relay suppression, click the Help button in the MercuryS SMTP Server configuration dialog.

Domain mailbox support   Mercury/32 now supports Domain mailboxes, or mailboxes that receive all mail directed to a specified Internet domain. With a domain mailbox, no verification is done on the username portion of the incoming e-mail address - everything gets put into the named mailbox. For more information on domain mailboxes, click the Help button in the Mercury Core Module configuration dialog.

Daemon support   A Daemon is a third-party DLL that can be associated with a specific mail address. When a message is sent to that address, Mercury loads the Daemon's DLL and passes it the message and a block of pointers to internal Mercury functions. Daemons could be used to handle automated sales enquiries, technical support, database queries, in fact, just about anything a programmer could write. No Daemons currently ship with Mercury, but it's likely that a number will become available during the first half of 1998. For information on the Daemon Interface, please mail David.Harris@pmail.gen.nz.

List signatures   You can now add signatures to your Mercury/32 mailing lists. A signature is simply a small text file that is automatically added to the end of every message distributed to the mailing list. In Digest mode, the signature is added as the last message in the digest. List signatures are a very handy way of including subscription/unsubscription instructions and other helpful information about the list. For more information on list signatures, click the Help button in the Mailing Lists configuration dialog or any of its sub-dialogs.

Minimizes to System Tray   When minimized, Mercury/32 now places a small icon in the Windows 95 or NT 4.0 System Tray area instead of keeping a full icon on the taskbar. Double-click the icon to restore the Mercury/32 main window.

List concealment option   You can now set a flag in the list definition that will prevent the Mail Server (Maiser) from reporting the existence of a list in response to a LIST command. This is handy for hiding private or internal lists that you do not want publicized.

Maximum submission size for lists  You can now define a maximum size that Mercury will apply to postings to a mailing list. Messages larger than the maximum size will not be posted to the list, and an error will be returned to the sender.

Hard quit option   There is now an option in the Mercury Core Module configuration dialog that, when checked, prevents Mercury from exiting except when "Exit" is chosen from the "File" menu while the Ctrl key is held down. This is useful for preventing accidental exiting from the program. When this option is turned on, attempting to quit normally will simply minimize the program to the system tray.

Changes to license, prohibition on use for UCE   In line with our standard policy, it is now prohibited under Mercury/32's terms and conditions of use to distribute or use it for the purpose of sending bulk unsolicited commercial e-mail ("spam"). For more information, please see the License... option on the Mercury/32 Help menu. I have also removed the ridiculous and discriminatory section of the license forcing people not using Pegasus Mail as their primary mailer to purchase manuals - I felt this section was contrary to everything I believe about communication. Anyone may now use Mercury/32 without obligation or fee regardless of the mailer they use (although naturally, we'd like people to use Pegasus Mail... :-) ).

Synonyms usable in standalone mode   Mercury synonyms (completely alternative address forms) can now be used in standalone mode (previously, they were only available in the NetWare environment). To use Synonyms in standalone mode, you need to create a synonym database using the FSYNONYM.EXE import program and make sure that that file is specified in the Files/Directories page of the Mercury core module configuration dialog. You also need to make a copy of the synonym database in the same directory as your copy of Pegasus Mail and reconfigure your copy of Pegasus Mail using the Mercury Pegasus Mail configuration option. For more information on synonyms, click here.

Help file   The Mercury help file has been enhanced and is now indexed.

The major problems fixed in this version are:

* Foreign aliases (aliases that resolve to a non-local address) now work properly

* The non-standard POP3 command XTND XMIT now works correctly.


Year 2000 Compliance

Mercury/32 v3.01 is Year 2000 Compliant. We have been able to find no lingering issues that could cause any date-related problems at the turn of the millenium.

For an in-depth analysis of the testing methodology we have used to determine the Y2K-readiness of Mercury and its companion product, Pegasus Mail, send any message to:

faq-y2k@pmail.gen.nz

To retrieve an automated FAQ file. Alternatively, see our web site -

http://www.pmail.gen.nz


An overview of the system

What is Mercury?

Simply put, Mercury is a mail server - it provides centralized transmission and reception of e-mail for all users on a network or workstation. It has powerful automation features, including some of the most powerful mailing list features in the industry, and comprehensive mail filtering and plugin interfaces. It has been designed to work with either permanent or dialup Internet connections - if you use a dialup connection, installing Mercury to act as your mail server removes the need for all your workstations to be able to connect to the Internet to send or receive mail.

Mercury/32 is a version of the Mercury Mail Transport System especially re-engineered for Win32 systems. The Mercury MTS is a proven, powerful Internet mail transport originally released as a set of NetWare(tm) NLMs, designed to run on Novell NetWare file servers. This version takes full advantage of the threading and pre-emptive multitasking of systems such as Windows 95 and Windows NT to provide an extremely smooth, powerful mail transport with a host of features, yet one that has negligible impact on the system on which it runs. Like its ancestor, Mercury/32 has excellent support for Novell NetWare systems, but can also run with very little maintenance on Windows NT and peer-to-peer networks, or even on single workstations, acting as a mail hub for a collection of local users.

Mercury has been designed as a perfect adjunct for the Pegasus Mail mail client, but will work excellently with any mailer that uses standard Internet protocols to send and receive mail.

Users will not normally interact with Mercury/32 directly - it is intended to run on a single workstation on your network, providing mail services to the network's users. Your users will normally run a compatible mail program, such as Pegasus Mail, to submit mail to and retrieve mail from the Mercury/32 system via shared directories on a server volume somewhere on your network, or by using the POP3/SMTP protocols.

Like both the original Mercury MTS and the Pegasus Mail System with which it is designed most closely to interoperate, Mercury/32 is free software, provided as a service to the broader Internet community. Please examine the License for details on the conditions of use of the Mercury/32 system.

Installation

To install Mercury/32, unpack the distribution archive in a temporary directory, then run the SETUP.EXE program you will find in it. Prior to running the setup program, you should know these things:

* The directory where Mercury/32 is to be installed

* The directory where your copy of Pegasus Mail is installed, if you

  intend to use Mercury/32 with Pegasus Mail

* Your Win32 machine's Internet Domain Name

* The address of a machine that can act as a mail relay (any unix

  system can usually do this, but make sure you get the system

  administrator's permission before using it). You only need this

  information if you are going to use the Mercury relaying SMTP

  client, MercuryC; if you are going to install Mercury as a full

  SMTP delivery transport, this setting is not required.

* The name of a local user who is to act as your Postmaster

Your Internet Service Provider should be able to give you the proper values for the last three items.

Users and addresses

If you are running Mercury/32 in Novell NetWare mode, then it will automatically use the NetWare user database (the "Bindery" or NDS, depending on the option you install) to find usernames on your system, and will deliver mail into each user's appropriate mail directory on the file server. No further configuration is required. You can configure Pegasus Mail to use Mercury/32 in NetWare mode using the standard Pegasus Mail PCONFIG utility.

If you are running Mercury/32 as a server for Pegasus Mail in non-NetWare mode, then Mercury will automatically find and use the users you have created in Pegasus Mail.

Information on using Mercury/32 with other mail systems is beyond the scope of this document - please contact Pegasus Mail Technical Support by e-mail to support@pmail.gen.nz for more information.

By default, a user's e-mail address will be "name@domain", where "name" is his or her NetWare or Pegasus Mail username, and "domain" is whatever you give the SETUP program as the Internet Domain Name of your local Win32 system. You can use special Mercury features called synonyms to set alternative addresses for your users if you wish.


License and terms of use
License, and terms of use

Mercury/32 is fully proprietary copyrighted software. David Harris ("The Author"), asserts his right to be recognized as the author and copyright owner under International Treaty and Copyright Law. The reservation of these rights notwithstanding, the Author wishes to provide the Mercury Software freely for the benefit of the broader Internet User Community, and especially for the benefit of users of his Pegasus Mail mail client.

You are granted a non-exclusive license to use the Mercury/32 software on as many computers as you wish subject to the following terms and conditions:

Consideration:  You may use the Mercury/32 software without any fee or charge, although you may at your option choose to license manuals as described elsewhere in this guide. You agree that the author of the Mercury/32 system receives consideration from your use of the program in the form of acclaim and valuable reputation, and that this consideration is sufficient to bind you to the terms of this license even if you opt not to purchase manuals.

Prohibited uses:  Mercury/32 may not be used as a transport for the dissemination of Bulk Unsolicited Commercial E-mail (commonly referred to as "spam"). For the purposes of this section, Bulk Unsolicited Commercial E-mail shall be taken to mean e-mail containing advertisements for products or services, which is sent to lists of more than 50 addresses where the addressees have not explicitly expressed interest in receiving such e-mail.

No transfer of rights:  You agree that your use of the Mercury software entails no transfer of intellectual property rights, copyright or ownership from the Author.

No liability:  The Mercury software is provided without warranty of performance. While the author has taken every care to ensure that the software works correctly and without fault, you agree to hold the Author blameless for any and all damage or loss caused by its use.

Distribution and supply:  You may distribute the Mercury/32 Software to any person or organization by whatever means you wish provided that:

a)	You do not charge more than reasonable handling or media production fees for the supply of the Mercury/32 Software itself.

b)	You do not represent ownership or title over the Mercury/32 Software.

c)	You supply the Mercury/32 Software complete and unmodified.

d)	You do not supply the Mercury/32 software as part of, or in conjunction with, any package or promotion explicitly designed for the purpose of disseminating Bulk Unsolicited Commercial E-mail.

Note: the author explicitly permits commercial distribution of the Mercury Software as part of Commercial Software packages provided the conditions of this license are fulfilled and the Author's written permission is obtained prior to shipping.


System Requirements

Mercury/32 is not a demanding application; it will run on almost any system capable of running  Windows 95/98/NT4 or Windows 2000, but for best performance we recommend the following configuration:

* Windows 95 or later

* Minimum 16MB RAM recommended on the system

* A properly-configured Windows Sockets Implementation for TCP/IP

  communications. Mercury/32 has been designed with dialup networking

  in mind, so SLIP and PPP links are fine.

* 1.5MB disk space for Mercury itself

* A compatible mail client, such as Pegasus Mail, or Eudora

* If you are running in NetWare mode, you must have a genuine Novell requester

  package installed on the workstation where Mercury runs.

Mercury/32 has support for all versions of Novell NetWare later than v3.10 (including NetWare 5.x) but does not require it - it can be used as a standalone mail server for (for example) a Windows for Workgroups or Windows NT network.


The configuration file, MERCURY.INI

Mercury reads and stores the majority of its configuration information in a file called MERCURY.INI, which must reside in the same directory as MERCURY.EXE itself. MERCURY.INI is a plain text file and can be edited using any standard editor (for example, the Windows NOTEPAD applet). The Mercury Setup program will usually create a basic MERCURY.INI for you, but you can customize it either by editing it directly, or more normally using the dialogs on the "Configuration" menu within Mercury itself.

The layout of the various sections of the MERCURY.INI file is described below, but you should also see the explanatory help within Mercury itself for other information.

The [General] Section

The [Mercury] Section

The [Domains] Section

The [Rewrite] Section

The [MercuryC] Section

The [MercuryS] Section

The [Groups] Section

The [Maiser] Section

Aliasing

Synonyms (alternative address formats)

Template files

Setting up Automatic Replies


The [General] Section

The [General] section contains settings common to all modules;

Myname: Domain name for your server; Mercury can derive the server's IP number from the OS, but it cannot derive the name. Enter here the name which your Name Server returns as the IN A entry for this file server. Unlike Charon, Mercury ONLY requires MX entries if you wish to provide aliased names for your servers.

Mailqueue: The name of the queue into which outgoing mail should be placed. is the queue directory (or spooler) into which Pegasus Mail and compatible clients will place mail for processing.

Timezone: The timezone string the Mercury modules should add to Date: fields in messages. This string must not be longer than 10 characters.

Example:

"timezone: +1100"

yields the date

"Mon, 29 Mar 93 23:10:33 +1100"

SMTPQueue: The name of the queue directory in which the SMTP client should look for jobs to send off-server. This can be the same as the mailqueue, and usually should be except  n exceptionally busy servers.

Newmail_path: In non-NetWare mode, this is the path used by Mercury to locate the new mail folder for each user on your system. If you are using Pegasus Mail as a mail client, then you should locate the directory that contains the file PMAIL.USR (and which should also contain all your users' new mail directories) then use that as your newmail_path value, with the characters "\~8" added onto the end.

Example: PMAIL.USR is in C:\PMAIL:

You would enter "newmail_path: C:\PMAIL\~8"


The [Mercury] Section

The [Mercury] section of MERCURY.INI contains settings for MERCURY.EXE, the central delivery engine. MERCURY.EXE is responsible for examining mail in the mailqueue and deciding whether it is to be delivered locally (which it will then do), or else passed to the SMTP client to be sent off-server. It also contains a simple Mail Server, and the aliasing and synonym mechanisms.

Failfile, Confirmfile: Template files, the first for Delivery failure notifications, the second for Delivery confirmations. Sample versions of these files are provided and can be used without changes. The template file format is described later.

Aliasfile: Points to a file of aliases. Aliases are equations for full addresses, and are created and maintained with MALIAS.EXE. The alias file may be updated while Mercury is running - for an example of the format of the source file used for aliasing, see the file ALIAS.SRC.

Syn_file: Points to a synonym file. Synonyms allow a user to have a From: address in messages which is different from their local username (which is the normal mail address when using Mercury and Pegasus Mail). Synonyms might allow user "DAVID", for instance, to use the address "D.Harris". Synonyms are created and maintained using the Pegasus Mail PMGRANT program, and the synonym database is created using CH_SYN.EXE, or NSYNONYM.EXE if you are running in NDS mode. The difference between Synonyms and Aliases is that Synonyms are bi-directional - that is, Pegasus Mail uses it in outgoing messages and Mercury recognizes it in incoming messages. Aliases usually only work in one direction. A user may have only ONE synonym, and need not have any if you choose not to use them.

Listfile: The name of the "List of lists" - a file defining mailing lists managed by Mercury. For more information, see the section below entitled Mailing lists.

Logfile: The name of a file where Mercury should record mail traffic. The sender, addressee, time, date and size of the messages are stored. If you do not specify a logfile field, no logging will be done.

Logwidth: Optional integer specifying the maximum width of address fields in the log file. The default value is 30 characters for each field.

BitnetHost: Mercury can perform limited, simple-minded address rewriting of BITNET addresses, which many smart mailers cannot mail directly. If you specify a value here (in the sample file, for instance, it is "cunyvm.cuny.edu"), then addresses in the form "USER@HOST.BITNET" will be sent as "USER%HOST.BITNET@cunyvm.cuny.edu".

Poll: How often (in seconds) Mercury should check for new jobs in the mailqueue. Once every ten seconds is a good setting.

Broadcast: An integer value (1 or 0, default 1). If you are using a Network support module (such as Mercury's NetWare support file), then it may be possible to send broadcast messages directly to a user's workstation. These broadcast messages are usually received either in dialogs, or under Windows 95, using the WINPOPUP program. If this setting is 1 and broadcast messages are supported on your network, Mercury will send a broadcast message to users if they are logged in when new mail arrives.

Receipts: An integer value (1 or 0, default 1). If 0, then Mercury will not send broadcast messages about the arrival of messages which simply advise "confirmation of reading". The mail itself will be delivered, but no broadcast message will occur. By default, Mercury will send broadcast messages for every new mail message which arrives. As with the Broadcast keyword, this option depends on your network supporting broadcast messages.

Gullible: An integer value (1 or 0) which determines whether or not Mercury should check that a message has a valid From: address before delivering it. If Mercury is to operate in Gullible mode (1), then it will accept any message and attempt to deliver it.

Scratch: Where Mercury can create temporary files. Usually the location in which you store your template files is a good choice.

Returnlines: How many lines Mercury should write from the original message when it encounters the ~G substitution in template files.

Postmaster: The local username of the user on this server who is to receive messages delivered to Postmaster. This cannot be an alias or synonym.

Note: PostMaster is a MANDATORY setting. Mercury will NOT run correctly if it is omitted. DO NOT AUTOFORWARD THIS ACCOUNT!

PM_Notify: An integer value (1 or 0, default 1) which determines whether or not Mercury should send copies of all delivery failures to the postmaster defined on the server. If set to 0, then Mercury will only return the error to the sender, not to the postmaster. Use this option with care - Mercury sends failure information to the postmaster for a reason, since it can indicate possible configuration errors on your system. If your postmaster is not prepared to field these messages, you should possibly consider appointing a new postmaster.

Change_owner: An integer value (1 or 0, default 0) which controls whether or not Mercury should change the ownership of mail it delivers to the recipient. If set to 1, then mail will count against the recipient's disk quota on the SYS: volume. This option should be used with care since in pathological cases it can result in loss of mail. This feature will only work on networks (such as Novell NetWare) that support the idea of file ownership.


The [Domains] Section

The [Domains] section is used to tell Mercury about the possible names by which your server might be known to other machines on your TCP/IP network. You must list in this section every domain name (the portion of an address following the '@' symbol) which might be used to mail to your server, since Mercury determines whether or not an address is local based on this information. Omitting server domain names from this section will almost certainly result in mail loops. Entries in the [Domains] section bind a particular domain address to a particular local system (for instance, a NetWare file server, or in non-NetWare mode, a workgroup). You must supply at least one domain for Mercury to function. The format of the Domains section is:

Server_name:  domain_name

As an example, if you have a NetWare server for which the NetWare name is THALIA, and the Internet name is URANIA.PMAIL.GEN.NZ, then your [Domains] entry will look like this:

THALIA : urania.pmail.gen.nz

To allow local delivery, you should always add an entry which equates your server name to your server name - like this:

THALIA : THALIA

Mercury will NOT add this entry automatically in case you have  unusual duplicate naming schemes at your site.

In non-NetWare mode, the "server" component of [Domains] entries is ignored but must still be present.

Domain literals: There is a seldom-used address format called a domain-literal form, which consists of the IP address of the target machine in square brackets (example _user@[192.156.225.2]_).

Although the domain-literal form is discouraged in standards documents, some older mail systems use it from time to time.

Mercury will accept domain literal references, but will not do so automatically - to allow domain literal forms, you must add an equation for them to your domains section, like any other domain reference. The form of the entry should be as follows:

SERVER : [www.xxx.yyy.zzz]

Example - your server's IP address is 192.156.225.16: you would enter this in your [Domains] section -

THALIA: [192.156.225.16]


The [Rewrite] Section

Mercury can perform limited rewriting on addresses in the envelope portion of outgoing mail; typically this will be used to ensure that addresses in the message envelope go out as FQDN forms, although it can also be used to perform a certain amount of crude domain rewriting as well.

Entries in the [Rewrite] section consist of a domain portion to match and the substitution to perform. For example, the [Rewrite] entry:

myserver :  myserver.pmail.gen.nz

tells Mercury to rewrite any addresses where the domain portion consists of "myserver" to a fully-qualified form. The match (left-hand side) is not case-sensitive, but otherwise must match exactly.

You can define a special "default rewrite" by specifying "*" as the match: this rewrite ADDS the substitution to any domain which does not contain a period in its domain portion. So the rewrite entry:

*:  pmail.gen.nz

Would cause the address david@parnassus to be rewritten as david@parnassus.pmail.gen.nz.

Restrictions: because the address rewriting facility is really just a string match and replace, there are certain restrictions on its use and capabilities:

* Source-routed address forms cannot be rewritten.

* Bang-style (uucp) addresses (anything containing a '!') will not be rewritten.

* The rewrite occurs ONLY in the ENVELOPE to the message, not in the actual message headers themselves.


The [MercuryC] Section

The MercuryC section contains settings for the Mercury SMTP client - the module which transfers mail from your server to the outside world using the SMTP protocol.

Scratch, failfile, returnlines, poll: Are all the same as in the [Mercury] entry, and may have the same values, or may differ. The Poll parameter in particular will usually be longer than the Poll time in the [Mercury] section.

Helo: Allows you to define a name different from "Myname" which MercuryC should use when connecting to the smart mailer. Most sites will not need to use this parameter.

Host: The Internet address of the host which MercuryC will ask to relay mail. Like the Charon SMTP gateway, MercuryC does not actually attempt to deliver mail itself - it passes it to a "smart" mailer which will do so. Typically the smart mailer is a UNIX machine. The Host address must be specified in dotted numeric format - for example 192.156.225.2.

Timeout: Specifies the number of seconds MercuryC should wait without seeing data on the socket before timing out. The default value is 300 seconds.


The [MercuryS] Section

MercuryS is the SMTP listener, which handles incoming SMTP mail.

Debug: If non-zero, then MercuryS will display more information about incoming connections on its screen.

Helo: Allows you to define a name different from "Myname" which MercuryS should use when accepting connections from other systems. Most sites will not need to use this parameter.

Refuse: The parameter is an Internet address in dotted format. This keyword defines an address or range of addresses from which MercuryS should NOT accept connections. (See next section)

Allow: The opposite of Refuse - specifies an address or range of addresses from which MercuryS SHOULD accept connections.

Timeout: Specifies the number of seconds MercuryS should wait without seeing data on the socket before timing out.

Size: Specifies the largest message MercuryS should agree to accept from mailers compliant with RFC1427 (the SMTP SIZE extension). The value is specified in bytes, with 0 (the default) meaning no limit.

Logfile: Indicates that MercuryS should record details of all incoming transactions in the file specified. This file MUST NOT be the same as either the Mercury log file or the Maiser log file. If this keyword is absent, no incoming logging will be performed. Be aware that the logfile generated by this feature can become very large very quickly, and should be purged regularly.

Listen on TCP/IP port  By default, MercuryS listens for connections from the outside world on port 25, which is the standard reserved port for the SMTP protocol. In some cases, particularly when you are behind a firewall, you may wish to listen on an alternative port - enter the number of that port in this field. Once you change this field and save the dialog, you will need to exit and restart Mercury/32 before the change will take effect.

MercuryS does no validation on incoming addresses unless relaying control is enabled - it simply places them as jobs in the Mailqueue, and allows MERCURY.NLM to decide what to do with them. MercuryS DOES support the SMTP VRFY command though.

Connection control

The Connection Control section allows you to place restrictions on the hosts from which MercuryS will accept connections. To add an entry to the list, type its IP address in the IP Address field and select either Allow or Refuse, then click Add. The digit 0 acts as a wildcard in a connection control entry, so adding an entry refusing access to 165.25.9.0 will cause MercuryS to refuse connections from any machine whose address's first three octets are 165.25.9. Note that there is an implicit rule Allow 0.0.0.0 at the end of this list, so if an address drops through the list, it will be automatically accepted.

To edit a connection control entry, highlight it in the list, edit the IP Address and Refuse/Allow controls, then click the Change button.

Controlling relaying

SMTP relaying is the standard method of propagating mail on the Internet: in normal operation, an SMTP host will accept any message destined for any user, even if that user is not a local user on the system: after it has accepted the message, it will relay it to the correct host for delivery. Mail agents like Pegasus Mail and Eudora routinely depend on relaying to send mail.

In recent times, relaying has been abused by perpetrators of mass unsolicited commercial e-mail (or "spam"), and many sites wish to control the way relaying is managed. Mercury provides two anti-relaying modes, normal and strict. Normal mode is turned on by checking the control labelled "Do not permit SMTP relaying of non-local mail". Strict mode is turned on by also checking the control labelled "Use strict local relaying restrictions". The default for these controls is both off.

In either mode, Mercury will always accept mail addressed to any local address.

In normal anti-relaying mode, Mercury will accept mail for delivery if either the recipient or the originator has a local e-mail address. If neither address is local, Mercury will compare the IP address of the connecting host to its connection control list (see above): if it finds an "allow" entry in that list that explicitly includes the connecting machine, then it will accept the mail, otherwise it will be failed with the diagnostic "571 - Sorry, we do not relay non-local mail".

In strict anti-relaying mode, Mercury follows the normal rules described above, but if the "From" address appears to be local, then Mercury will search the connection control list and will only accept the mail if an "allow" entry appears that explicitly permits the connecting host.

The difference between the two modes is that normal mode requires less setup and maintenance, but is less secure, while strict mode practically guarantees that no unauthorised relaying can occur at the expense of having to manage a list of permitted relay hosts.

When you configure Mercury to operate in strict mode, you must ensure that you add "allow" entries to your connection control list for every machine that is to be permitted to relay mail via this copy of Mercury. Note that this does NOT mean that you have to enter the address of every machine from which you want to accept mail - mail to local recipients is always accepted, regardless of the relaying mode. Strict mode only requires "allow" entries for machines from which Mercury is to accept mail to be delivered to non-local addresses.

Anti-relaying is turned off by default in Mercury, because relaying is the proper, defined action under the SMTP protocol. It is, however, almost always safe to turn on normal anti-relaying mode.


The [Groups] Section

If you are using a Network module (such as Mercury's Novell NetWare Support) that supports the idea of system-defined groups, then Mercury can deliver mail to to those user groups on your server. Because this is a potential security risk (imagine someone sending malicious mail to group EVERYONE), you have to enable mail to groups on a group by group basis.

To allow mail to a group, create a [Groups] section in your MERCURY.INI file, using the following syntax:

address  :  group_name

Address is the address which Mercury will associate with the group.It can be the same as the group's actual name if you wish. Group_name is the actual name of the group on your server.

Example:  to enable group mailing to group MAILUSERS using the address "everybody", enter:

[Groups]

everybody : MAILUSERS

You may have as many entries in the GROUPS section as you wish.


The [Maiser] Section

As mentioned above, Mercury incorporates a powerful mail server, (also sometimes known as a mail robot, or mailbot) which can respond autonomously to a number of commands in response to a mail message. The [Maiser] section controls the Mail Server. If it is absent, the Mail Server functions will be disabled.

Maiser: The name of the address which Mercury should interpret as being the mail server. This should NOT be a valid account on your server - it is a fictitious address to which mail is never directly delivered: setting MAISER to point to a real account effectively prevents the real account from ever receiving mail. The value in the sample INI file is MAISER, and I STRONGLY urge you to use this name unless you have extremely solid reasons for altering it.

Helpfile: The name of a file which the mailserver should send back in reply to the message body "HELP". A sample file is provided which you may use if you wish. This file is NOT a template file.

Lookupfile: The name of a template file which the mailserver should use to form replies in response to the LOOKUP command. This IS a template file, and should contain the substitution "~R" at the point where the mail server should enumerate the successful matches. If you do not supply a value for Lookupfile, the Maiser's lookup function will be disabled, and anyone requesting a lookup will receive a failure notification to this effect.

Logfile: The name of a file where MAISER should record traffic. The sender, time, date and commands issued are recorded. If you do not specify a logfile field, no MAISER logging will be done.

*** DO NOT set the Maiser log file to the same file as the

*** Mercury log file.

Send_dir: The name of a directory containing files which users may ask the maiser to send using the SEND command. Files in this directory must be ASCII text files, so if you want to make binaries available you will have to uuencode or binhex them yourself. If you choose to make files available by mail, you should place a file called INDEX.TXT in this directory: this is the file Maiser will send in response to the INDEX command, and usually contains descriptions of the available files (although it can contain anything). The send command is quite secure - it will ONLY accept filenames in the specified directory. If you wish to disable the send command, then make sure that there is no Send_dir field in your MAISER section.


Aliasing
Aliases

Mercury supports disk-based aliasing for addresses. Aliases may be created, added or updated while Mercury is running.

To use aliases, create a text file containing the alias equations then compile it using MALIAS.EXE. The resulting file should be placed in the location specified in MERCURY.INI.

For an example of the format MALIAS expects, examine the file ALIAS.SMP provided in the distribution archive (the setup program places this in the MERCURY subdirectory of the directory where you install the system).


Synonyms (alternative address forms)

Many sites need to use custom address formats where the user's e-mail address is quite different from his actual user name on the system. For example, you may want your addresses to have the form Firstname.Lastname@host.domain. Simple aliasing won't allow you to do this kind of addressing easily - it will handle incoming mail well enough, but in order to get mail going out from your system to use the alternative address forms requires the co-operation of your mail client.

Pegasus Mail and Mercury/32 can combine to support alternative address forms like this (referred to as synonyms) using a special database called a synonym database: Mercury needs this database so it can work out the recipient for incoming mail, while Pegasus Mail needs it to work out what address it should write into outgoing messages. Using synonyms differs slightly depending on whether or not you are running in Novell NetWare mode:

* If both Pegasus Mail and Mercury are running in NetWare mode:  create your synonyms using the Pegasus Mail PMGRANT (or NPMGRANT in NDS mode) commandline program, then create the Mercury synonym database using the CH_SYN.EXE (or NSYNONYM.EXE in NDS mode) commandline program. Copy the synonym database somewhere accessible by Mercury, and make sure the Synonym database file entry of the Files/Directories preferences page of the Mercury core module configuration dialog refers to that file. Pegasus Mail will automatically pick up each user's synonym from the NetWare user database.

* If either Pegasus Mail or Mercury is running in non-NetWare mode, then you will need to follow these steps:

1: Create a synonym source file: this is a text file where each line has the form

username == synonym

So, on the left-hand side you place the user's local name, and on the right hand side his or her e-mail address as you want it to appear in outgoing mail. Note that each line must begin hard against the left-hand margin.

2: Compile the source file using the FSYNONYM commandline program. FSYNONYM takes your input file and creates a synonym database file.

3: Copy the synonym database somewhere accessible by Mercury, and make sure the Synonym database file entry of the Files/Directories preferences page of the Mercury core module configuration dialog refers to that file.

4: Copy the synonym database file into the same directory as your copy of the Pegasus Mail executable file (either WINPMAIL.EXE or WINPM-32.EXE), making sure it is called SYNONYM.MER.

5: [Only required once] Use the Pegasus Mail option on the Mercury configuration menu to configure your copy of Pegasus Mail. This operation is only required if you have upgraded your copy of Mercury from an earlier version, and only needs to be done the one time: it creates a new version of PMGATE.SYS that instructs Pegasus Mail to use the synonym file if it exists.

Note: in order to use synonyms in non-NetWare mode, you must be using Pegasus Mail for Windows v3.01b or later. Earlier versions will not recognize the synonym database and will use the user's regular e-mail address instead.


Template files

Mercury is capable of generating a certain number of messages autonomously: good examples are Delivery Confirmations and Delivery Failure messages. Rather than use hard-wired messages (like sendmail's awful delivery confirmations), Mercury allows you to create Template Files - pre-written models which it will use to write the messages, filling in the blanks as necessary.

Template files are complete messages, including headers, and must be formatted as such. Template headers must conform to RFC-822, but the message body of a template can contain anything you wish. You can tell Mercury to substitute certain values in a template by placing a tilde followed by a code at the point in the message where you want the substitution to occur. The following Template substitutions are supported by Mercury:

~D	Replaced with the current time and date in full RFC-822 date format, without the "Date:" keyword.

~T	Replaced by the "to" address of the message, without the "To:" keyword.

~S	Replaced with the "Subject:" field for the message, without "Subject" keyword.

~R	Indicates the point in the template at which Mercury should print its result file. For delivery failure, the result file contains the errors; for user lookups, it contains the result of the search; for delivery confirmation, it contains the addresses to which the message was successfully delivered. Its value for other templates is undefined.

~M	Indicates that Mercury should dump the entire original message into the outgoing message.

~G	Indicates that Mercury should dump lines from the original message, up to the value defined in "returnlines" in MERCURY.INI, into the outgoing message.

~N	Replaced with the domain name of the server.

~~	Replaced with a single tilde.

Other substitutions may be added in future versions. The Mercury distribution includes the following sample template files which you can use unmodified at your site if you wish: FAILURE.MER (Delivery failure notification), CONFIRM.MER (Delivery success notification) and MAISER.LKP (template for a successful MAISER lookup operation).


Setting up Automatic Replies

Mercury can manage auto replies for Internet mail, much the same way the UNIX "Vacation" program does. To enable auto-reply for a user, create a file in his/her new mail subdirectory called AREPLY.PM, containing the message to be returned to the sender. Mercury will look for this when delivering mail to the account, and will return its contents immediately the message is delivered locally.

To avoid the possibility of mail storms (which can happen when two accounts start auto-replying to each other, or when an autoreply is sent to a list server), Mercury remembers every address from which a message has been successfully delivered for the account in the last 48 hours; if more than one message comes in from the same address in any 48 hour period, Mercury will generate only one auto-reply. The auto-reply memory is stored in a file called AREPLY.KFL in the user's new mail directory.

You can also specify a static kill file for autoreplies on a user by user basis. When generating an autoreply, Mercury checks to see if there is a file called AREPLY.KFS in the user's mail directory. If there is, it is checked for the address before the autoreply is transmitted. AREPLY.KFS differs from the AREPLY.KFL file Mercury generates automatically in that Mercury never changes or deletes it. It is provided to allow a user to suppress certain autoreplies permanently. Addresses should be entered into AREPLY.KFS one per line, in their simplest form.


Mailing lists

One of Mercury's most powerful features is its ability to handle mailing lists, or lists of mail addresses grouped under a single address. Mailing lists can be set up with a wide range of options, and can be managed autonomously, without human intervention.

Terminology

The "List of lists"

Using mailing lists


Mailing List Terms

As we discuss Mercury's mailing lists, we will use certain terms to describe features or actions, including the following:

List of lists:  The master file describing all the lists managed by Mercury on this host. Specified in MERCURY.INI.

Public list:  A public list is one to which anyone may subscribe by sending a subscribe message to the mail server. If a list is not public, then only the list moderators may add to it by e-mail. A non-public list with no moderator can only be added to by manually editing the list file.

Moderator: The address of a person who has control over the list. If a list is "moderated" (see below) then mail can only be sent to the list by a moderator. If a list is "non-public" (see above), then only a list moderator may add subscribers to it. A list may have a practically unlimited number of moderators. A moderator need not be a subscriber to the list.

Restricted list:  If a list is restricted, only its members and moderators may send mail to it.

Moderated list:  A moderated list can only be posted to from addresses specified as moderators of the list. The intention is that mail is sent to a moderator who then decides whether it should be posted to the list. Moderated lists may or may not be public as well.

Anonymous list:  Mercury supports anonymous lists, or mailing lists which suppress information about the identity of anyone who sends mail to them.


The "List of Lists"

The "List of Lists" is a file named by the "listfile" entry in MERCURY.INI. It is a simple text file containing information about the lists available on this host, and may be updated at any time. List names start at the extreme left margin, and all subsequent lines describing the list must be indented at least one space. Description lines for a list are read until a blank line or another list name is encountered. The name of a list may not have a domain attached lists can be reached on any domain served by the host.

Example:

test-l

   file:	c:\mercury\mercury\testl.lst

   title:	Test List

   welcome:	c:\mercury\mercury\testlw.txt

   moderator:	david@calliope.pmail.gen.nz

   moderator:	dlh@urania.pmail.gen.nz

This entry defines a list called "test-l", with two moderators, a title, and a greeting file for new subscribers. Note that it is almost always easier and preferable to manage your mailing list definitions using the Mailing Lists option on the Mercury Configuration menu; this section is provided for technical information only.

The following keywords are recognized in the list of lists:

FILE: A required qualifier - the name of the file which actually contains the current membership of the list. The file need not exist before use - Mercury will create it automatically if necessary.

TITLE: Optional. Text added to the "to" field of messages sent out to list subscribers.

WELCOME: Optional. The name of a file to send to new subscribers to this list. The file is plain text, not a template file.

FAREWELL: Optional. The name of a file to send to subscribers when they are removed from this list. The file is plain text, not a template file.

MODERATOR: The minimal-form address of a list manager. List managers may add users to the list and may be the only people able to mail to the list. You may have as many MODERATOR entries as you wish, one address per entry. The FIRST moderator entry has special  significance - it is the "primary" moderator, the one to whom MAISER will refer users.

PUBLIC: Optional, Y or N (Default Y). Indicates whether the list is public or not. Non-public lists will not accept SUBSCRIBE requests.

RESTRICTED: Optional, Y or N (Default N). If 'Y', then only list members and moderators may send mail to the list.

MODERATED: Optional, Y or N (Default N). If 'Y', then only the list moderators may post to the list.

LIMIT: Optional, number (default 0). The maximum number of subscribers the list may have. If 0 (the default) then there is no limit.

ERRORS_TO: Optional, no default. Supplies an address to which errors generated by list mail should be sent. Note that this merely tells Mercury to place the given address in the message envelope and to generate an Errors-to: header in the message, which is quasi-standard. There is NO reliable way of controlling or directing list errors, but this is as good as there is. Whether it has any effect depends on the receiving mailer.

REPLY_TO_LIST: Optional, Y or N (Default N). If 'Y', then Mercury will add a "Reply-to" field in messages to the list which will direct replies to the list rather than the sender.

ENUMERATE: Optional, Y or N (default N). If 'Y', then Maiser will accept ENUMERATE/REVIEW requests for the list.

FANOUT: Optional integer, default 1. Specifies the number of jobs Mercury should create when exploding this list. When a list is "fanned" (spread across multiple jobs) Mercury attempts to create the number of jobs you specify in this keyword and distribute the addresses evenly between them. This can result in faster distribution for large lists, especially if you load multiple copies of MERCURYC pointed at different smart mail hosts.

ARCHIVE: Optional path to a file, no default. If present, this entry specifies the name of a file into which all mail sent to the list should be copied (an archive). You can automate the creation and naming of archives by using special "template" characters in the filename - the following templates are available:

~Y   Year (2 digits)

~M   Month (1 or 2 digits)

~D   Day (1 or 2 digits)

~W   Current week in the year.

Example: the filename

C:\MERCURY\MERCURY\MAIL~D

could be used to create and maintain weekly archives of a list.

ANONYMOUS: Optional, Y, N or T (default N). If 'Y', mail to the list will be "anonymized" (ie, all sender references will be removed), but the sender's details will be logged in the Mercury log file. If 'T', then the log entry will also be suppressed.

DIGEST_NAME: Simple filename indicating that digests are supported for the list. A digest is simply an accumulation of mail sent to the list which is sent out periodically to those members in digest mode. Digest sending can be triggered by either time or size. Users can set digest mode for their subscription using the mail server SET command. NOTE: the filename parameter to this keyword must NOT have a path - Mercury will automatically create it in the directory pointed to by the "scratch" entry in the [Mercury] section of MERCURY.INI.

DIGEST_MAXWAIT: The maximum length of time a digest can accumulate, in whole hours. Once this time has elapsed, the digest will be processed and sent to those users subscribed in digest mode. The default value is 24 hours.

DIGEST_MAXSIZE: The maximum size (in bytes) a digest can reach before being sent. Once the digest reaches or exceeds this size, it will be processed and sent to those users subscribed in digest mode on the next hourly poll. The default value is 32MB (ie, no practical limit).

DIGEST_DEFAULT: Optional Y or N (default N). If 'Y', new subscribers to the list will automatically be added in digest mode.

TITLE_IS_ADDRESS: Optional Y or N (default N). If present and set to Y, this tells Mercury that the TITLE field contains a full, legal, domain-extended RFC822 address and forces it to suppress its usual address formation rules for the list. This is the ONLY way to control the actual list address Mercury will print in mail sent to the list and should be used with extreme care, since invalid addresses can cause mail storms.


Using Mailing Lists

Mercury supports autonomous list management using its built-in mail server (usually called MAISER). Users can perform most list-related actions by sending a message to 'maiser@host.domain' with commands entered into the message body, one per line. The following commands are recognized for list management.

Commands available to subscribers

SUBSCRIBE <list-name>	Add the sender's address to the list

(also SUB <list-name>)

UNSUBSCRIBE <list-name>	Remove the sender from the list

(also UNSUB <list-name>,

or SIGNOFF <list-name>)

ENUMERATE <list-name>	Return the list membership

(also REVIEW <list-name>)

LIST	Returns the lists available at this host

SET <list-name> DIGEST	Set your list subscription to digest mode

SET <list-name> NODIGEST	Turn off digest mode for a list.

SET <list-name> MAIL	Turn on delivery from a list

SET <list-name> NOMAIL	Turn off delivery from a list

STATUS <list-name>	Get current subscription information for a list

Commands only available to list moderators:

ADD <list-name> <address>	Add a user to a list

REMOVE <list-name> <address>	 Remove a user from a list

MSET <user> <list> <option>	Change a user's subscription options

- option can be MAIL, NOMAIL, DIGEST or NODIGEST

MSTATUS <list-name> <user>	Get a user's subscription status

PASSWORD <password>	Supply the password for moderator commands

Users can subscribe to Public lists by sending a message to the MAISER account on the server with the body set to SUBSCRIBE <list-name>. Users can unsubscribe from a list using the command UNSUBSCRIBE <list-name>. If a list is not public, then moderators can add users to it by mailing to MAISER with the message body set to ADD <list-name> <e-mail-address>, and may remove users by setting the message body to REMOVE <list-name> <e-mail-address>. The command ENUMERATE <list-name> will return the current list membership. If a moderator has been specified for the list, then ENUMERATE will only work for moderators, even if the list is not flagged as moderated.


The POP3 Server
The POP3 Server Module

Mercury includes a mail forwarding server which conforms to the Internet Standard, RFC-1725 (POP3, or Post Office Protocol v3). The POP3 Module is called MERCURYP.DLL, and can be loaded with or without the other Mercury components.

MercuryP is a full implementation of all commands in RFC1725 (although RPOP is treated no differently from PASS), and any legal POP3 client should be able to access it on port 110.

Configuring MercuryP

User POP3 passwords

User-specific POP3 profiles

System-wide POP3 profile

Suggested POP3 profile settings:

Suggested profile settings for Pegasus Mail

Suggested profile settings for PMPOP

Suggested profile settings for Eudora


Configuring MercuryP

MercuryP can be run on its own, or in conjunction with the other Mercury system modules. It has its own section in MERCURY.INI, called [MercuryP], which can contain the following keywords:

Scratch : <path>  Points to a directory in which MercuryP can create temporary files.There is no default.

Mark_read : <1 or 0>  Controls whether or not MercuryP should mark messages which are downloaded but not deleted as read when the connection is closed. Combining this option with the option many POP clients of not deleting downloaded mail provides a way of getting only new mail from the server while leaving it there for later use when attached.

Note:  the Mark_Read switch duplicates the capabilities of the user profile, POP3.PRO, described in the next section, on a global basis.


User POP3 Passwords

In order to retrieve mail from a POP3 server, a user must give a password that matches the account from which they wish to get mail. When Mercury is running in Network mode using a network support module (such as its Novell NetWare support module), then the user's password is held by the Network operating system and MercuryP will attempt to validate it there; so, in NetWare mode, a user's POP3 password is his or her NetWare password.

If you are running Mercury in a non-network environment, or in a network environment for which Mercury has no support module, then there is no password at the system level that Mercury can use. Instead, you must provide passwords for each user by creating a file called PASSWD.PM in each user's new mail directory. PASSWD.PM should contain the following single line of text:

Pop3_Access: XXXXXX

Where "XXXXXX" is the user's POP3 password. The line must be placed against the left margin, and the password is case-sensitive.

A future revision of Mercury will support encrypted passwords for users.


User-specific POP3 profiles

Each user in the system can have a file called POP3.PRO in his new mail directory which contains settings MercuryP will use when a POP3 connection is established. POP3.PRO is a simple text file, editable with any text editor (such as the DOS EDIT command). The following keywords can be used in it:

Mark read : <Y or N>  If Y, then MercuryP will mark as having been read any messages downloaded during a session but not deleted.

Show read : <Y or N>  If Y, then MercuryP will show all messages in the user's new mailbox when asked for a list by a POP3 client. If N, then only mail which has NOT been marked as read will be presented.

Show status : <Y or N>  If Y, then MercuryP will generate artificial "Status:" headers such as might be found in a Unix mailbox. Usually these headers are not present since neither Pegasus Mail nor Mercury relies on them for status information about the message, but other POP3 mailers (such as Eudora) rely on these headers to provide functionality.

No delete : <Y or N>  If Y, then MercuryP will not delete messages even when instructed to do so by the POP3 client. This is useful if you are using a POP3 client which cannot be configured to leave messages on the server, and you want to do so.

Delete is final : <Y or N>  If Y, then any mail deleted using the POP3 DELE command will be deleted if the connection to the server is lost. The default condition is for mail deleted using DELE to be recovered if the connection terminates abnormally. If you routinely access your mail across a slow or unreliable TCP/IP link (e.g, SLIP) you may prefer to set this to Y.


The System-wide POP3 profile

As well as user POP3 profiles (see the previous section) you can define a system-wide POP3 profile by creating a file called POP3.PRO using the same syntax, in the same directory as MERCURYP.DLL. The system-wide profile is read first, and then the user profile (if any) is applied. Settings in the files are cumulative, so a setting applied in the system profile will remain after a user profile is read unless the user profile explicitly alters it.


Suggested POP3 profile settings for Pegasus Mail

Pegasus Mail for Windows has built-in POP3 support. If you want to leave your mail on the server for later browsing when connected to the LAN, but only want to be presented with new (unread) mail via POP3, then use the following profile settings:

Mark read : Y

Show read : N

Show status : N

No delete : N

Delete is final : <your preference>


Suggested POP3 profile settings for PMPOP

PMPOP is the POP3 gateway for the DOS version of Pegasus Mail:If you want to leave your mail on the server for later browsing when connected to the LAN, but only want to be presented with new (unread) mail via POP3, then use the following profile settings:

Mark read : Y

Show read : N

Show status : N

No delete : N

Delete is final : <your preference>


Suggested POP3 profile settings for Eudora

The recommended settings when using Mercury with Qualcomm's "Eudora" POP3 mailer in its "Leave mail on server" mode are as follows:

Mark read : Y

Show read : Y

Show status : Y

No delete : N

Delete is final : <your preference>

Eudora has its own mechanisms (using the unix "status" header) for determining whether mail should be downloaded or not, so the normal mechanisms provided by MercuryP should be suppressed.


The Mail Server

As well as providing automated control of mailing lists, Mercury's mail server also recognizes the following commands; to use these commands, send a message to the Mail Server account (usually called "maiser") with the message body containing the commands you want it to execute, one per line. The Mail Server will process commands until it encounters a blank line or an EXIT command.

HELP  Returns the helpfile defined in the MAISER section of MERCURY.INI to the sender.

BOUNCE  Returns the message to the sender, headers intact.

LOOKUP <string> Searches the local system for user names matching <string>, which can contain '*' and '?' wildcards. If you wish to disable lookup, make sure that there is no LOOKUPFILE entry in the MAISER section of your MERCURY.INI.

VERIFY <address>  Returns a message indicating whether the address specified is valid on the local host.

INDEX  Sends the file INDEX.TXT from your "files to send" directory (identical to the command SEND INDEX.TXT).

SEND <filename>  Sends the named text file from your "files to send" directory. If you do NOT want this facility to be available on your system, make sure that there is no SEND_DIR entry in the MAISER section of MERCURY.INI. The send command is VERY secure - you cannot specify paths of any kind in <filename>, and Mercury will ONLY look in the directory specified in SEND_DIR.

FINGER <address>  Returns information about the address supplied. Also returns the contents of the file PROFILE if it exists in the specified user's new mail directory (useful for PGP keys and the like).

EXIT  Stop processing commands from the mail message.


Manuals

Mercury is free software, but to support its development, I make manuals available for sale. Two types of manual are available - single licenses, and licenses which allow you to make as many copies as you wish for use at your site. Purchasing any manual license also gets you direct access to our technical support engineers. The manual for Mercury is a combined manual applying to both the NLM and Win32 versions of the system.

A single copy license gets you one copy of the Mercury Manual and the most recent version of the program on CD-ROM. You may not make make further copies of the manual, other than the single copy for archival purposes which is permitted by copyright law. Single copy licenses cost US$150.

Site licenses get you a single master copy of the Mercury manual and a license which permits you to duplicate that master copy as many times as you wish for use at your site. As with Pegasus Mail, a "site" is considered to be the extent of your organization in one city. Site licenses cost US$300, and again include a current version CD-ROM.

If you already hold a site license for any version of Pegasus Mail, you may claim a US$75 deduction from the price of a Mercury Site license. No deduction applies to single-copy license purchases.

Remember that manual purchases are optional - there is no obligation for you to purchase manuals for Mercury, but if you do so, you are making a positive contribution to its development and helping us to support it.

How to order manuals

Payment by credit card

Terms and conditions of orders

Order form for Mercury Manuals


How to order manuals

To order a Mercury Manual, please print and fill out the order form (a copy of the order form is also supplied in ASCII format as ORDER.FRM). Then send it with your cheque or purchase order to:

Pegasus Mail, c/- David Harris,

P.O. Box 5451,

Dunedin,

New Zealand.	(or Fax +64 3 453 6612)

Company purchase order forms are accepted from any educational or charitable institution or government department, and from companies with a paid up capital in excess of $30,000.

Payment must be made in US dollars, drawn on a US bank. There is usually a delay of around 7-14 days before a manual can be sent out, and we reserve the right to hold your order if a new release is pending (so you can get the new release). Manuals are always sent by Courier (2-4 day delivery anywhere in the world); the cost of freight can be calculated using the freight table.

All manual orders are shipped with a CD-ROM containing the most recent versions of the program.

PLEASE, PLEASE! Remember to enclose the order form: I'm not psychic, and I can't guess at delivery addresses from a cheque alone...


Payment by credit card

We can accept payment for Manual orders on any valid VISA or Mastercard. If you wish to pay this way, please note your card number, expiry date, and the name on the card on the order form, and make sure you sign our order form. We cannot accept Diners Club or American Express.

Special Conditions:

*  The amount you are billed will probably not be exactly the amount on the order, because we have to submit the voucher to the VISA Centre converted to New Zealand dollars. We will use the USD conversion rate that applies on the day your order is processed.


Freight costs
Freight costs for shipping manuals

Manuals are shipped via Courier to any location in the world. The delivery time is usually 3-4 days and is fully traced. Freight costs are as follows:

When ordering one manual, add:

To Australia and New Zealand	US$15.00

To the U.S.A. and Canada	US$27.50

To the U.K. and Europe	US$32.50

All other destinations	US$37.50

When ordering two or more manuals, or any Pegasus Mail Bundle option, add:

To Australia and New Zealand	US$20.00

To the U.S.A. and Canada	US$34.00

To the U.K. and Europe	US$39.00

All other destinations	US$45.00

Examples:

* Shipping a Mercury site license to Sydney, Australia, add US$15

* Shipping a DOS and Windows bundle to Cincinatti, U.S.A, add US$34

* Shipping four Mercury Single-copy manuals to Germany, add US$39.00


Terms and conditions of orders
Terms and conditions applying to orders

The following terms and conditions apply to all orders for Mercury MTS manual sets. Submitting an order indicates acceptance of these terms and conditions in their entirety, over and above any waivers, disclaimers or conditions stated on the order itself.

Site license  A site license for Mercury MTS manuals provides you with one master copy of the manual and a license permitting you to make an unlimited number of copies of that master for use at one site. A "site" is defined as the extent of an organization in one metropolitan area, so if you have four offices in one town, one site license will cover them all. Only ONE organization may hold a site license - you may not distribute copies of a site-licensed master outside your organization. Note that State or National Governments and Local bodies do not consitute organizations for the purposes of this definition. Site licensed manuals include ASCII and RTF versions of the manual on diskette.

Single copy license  You receive a single master copy of the manual, and a license permitting you to make exactly one copy of that original for archival purposes only.

Media  All manual licenses include a CD-ROM with the most recent version of the Software.

Credit terms  Our terms for payment on credit are STRICTLY net 30 days. No monthly statement is issued - we require payment on invoice.

Deductions  We require that the total amount of our invoice be paid to us; it appears to be "standard operating procedure" for some banks to deduct fees before sending payment to us, which we will not accept. Please double-check that your bank understands that no deductions must be made from the amount sent to us or your payment will be rejected.

Freight charges  Manuals are always shipped via Courier anywhere in the world, and the freight cost is extra. Our courier usually provides a four-day service to any destination. We can ship via airmail on specific request, but are unable to ship via other carriers (such as FedEx, UPS or DHL). Freight prices can be calculated using the freight table.

Prepayment  If you prepay your order, your payment will not be presented until the day your manual is shipped. In general, we prefer that you do not prepay orders - we would sooner receive a purchase order and accept payment on invoice.

Pro-forma invoices, acknowledgments, quotations and bids  Because of the sheer volume of paperwork we have to process, we regret that we cannot supply pro-forma invoices, quotations or bids, and cannot acknowledge receipt of orders other than via e-mail on specific request only.

US IRS taxpayer requirements  The vendor is not an American citizen and is not resident in the United States for tax purposes: consequently, requests for FEINs, social security numbers or other US Taxation requirements cannot be complied with and will receive no reply.

Withholding taxes on payments  We will not accept payments from which withholding tax deductions have been made unless those deductions have been made in compliance with the laws of New Zealand. If you deduct withholding tax from your remittance, your payment will be rejected even if you do so in compliance with the laws of your own country. Such deductions are a matter between you and your own government.

Credit card payments  Credit card payments will be converted to New Zealand dollars using the prevailing exchange rate on the date your manual is shipped to you. The amount you see on your credit card statement will probably not be exactly the amount shown on the order form because of currency conversions.


Order form

Please read Terms and Conditions carefully before placing your order.

         +--------------------------------------------------+

         |         O R D E R   F O R M,   v 3 . 0 1         |

         |              for Mercury/32 Manuals              |

         |     Order form valid until November 1st 2000     |

         +--------------------------------------------------+

 Ship to:                            Bill to:

[                            ]      [                               ]

[                            ]      [                               ]

[                            ]      [                               ]

[                            ]      [                               ]

[                            ]      [                               ]

Date this order was mailed          [   ] Day  [   ] Mon  [   ] Year

What is your purchase order number  [                               ]

 or: Credit card type (tick one)    [   ] Visa [   ] Mastercard

     Card number (print carefully)  [                    ] exp: [   ]

     Name shown on card             [                               ]

Number of invoice copies required   [   ]

Internet e-mail address of contact  [                               ]

Fax number of contact               [                               ]

Order status and update information cannot be sent if you do not provide either a contact e-mail address (preferred) or a fax number. If paying by credit card, you must sign the copy of this order form you send to us.

Please supply the following items:

----------------------------------------------------------------------

[  ] Single manual license for Mercury @ US$150 . . . .  US$ [       ]

[  ] Site-licensed manual for Mercury @ US$300  . . . .  US$ [       ]

Freight cost calculated using freight list               US$ [       ]

[  ] We already hold a Pegasus Mail SITE license - please give

     us a US$75 deduction from a Mercury ->SITE<- license purchase!

     (Discounts do NOT apply to single-copy license purchases).

----------------------------------------------------------------------

Ordering instructions:  Please complete this form, and send it via airmail with your cheque or purchase order to:

    Pegasus Mail, c/- David Harris,

    P.O. Box 5451, Dunedin,

    New Zealand.

or fax it and your purchase order number to: (+64) 3 453-6612.

Please allow 7-14 days for your order to be processed.